The 1879 and 1880 lines are still be replaced by mv's target descendant, it's parent may be shared with a wrong node, so I think this solution is not very is not very correct.

If I don't commit, the RelNode is

LogicalCalc(expr#0..1=[{inputs}], deptno=[$t0])
  LogicalJoin(condition=[=($0, $1)], joinType=[inner])
    LogicalUnion(all=[true])
      LogicalCalc(expr#0..1=[{inputs}], deptno=[$t1]) -- same as 1879
        LogicalCalc(expr#0..4=[{inputs}], proj#0..1=[{exprs}]) -- same as 1880
          LogicalTableScan(table=[[hr, emps]])
      LogicalAggregate(group=[{1}])
        EnumerableTableScan(table=[[hr, MV0]])
    LogicalAggregate(group=[{0}])
      LogicalCalc(expr#0..4=[{inputs}], deptno=[$t1])
        LogicalTableScan(table=[[hr, emps]])

There are two LogicalCalc, do you mean this is Error?

Yes, because these two LogicalCalc operators both are replaced by mv's target descendant, I think these temporary replacements should be undo after the real replacement has been done. This is the correct solution for this problem.

I think getInputs.get(currentInputIndex) is just a walk-around to force traverse the missed nodes. Actually, preOrderTraverseNext method can traverse all the nodes of this plan tree, There is no need to add a new status to record the current node's position.

It is a demo.

I think that it always get(0) is error.
We should find a better way to traverse the missing nodes.

I think get(0) is correct, get(0) is just a starting point when traverse child-nodes, preOrderTraverseNext method can traverse the missing nodes.